The present invention relates generally to a method for timing computer processes or tasks and more specifically to a timing method for accurately timing software processes in a multitasking operating system of an automatic call distributor system.
Automatic call distributor (ACD) systems are typically used by businesses to automatically route incoming customer telephone calls to available sales agents. ACD systems generally include a multiport switch controlled by a central processing unit to interconnect external telephonic units of an external telephonic network with internal agent telephonic units. An example of such an ACD system is disclosed in U.S. Pat. No. 5,140,611 issued to Jones et al. on Aug. 8, 1992, entitled xe2x80x9cPulse Modulated Self-Clocking and Self-Synchronizing Data Transmission and Method for a Telephonic Communication Switching System,xe2x80x9d owned by the common assignee of the present patent. The disclosure of U.S. Pat. No. 5,140,611 is hereby incorporated by reference.
ACD systems include at least one central processing unit and often, include many distributed processing units located on various hardware circuit cards of the system. Usually, one processing unit is responsible for the execution of the operating system, although parallel processing permits multiple processors to xe2x80x9csharexe2x80x9d the execution of software tasks. For purposes of illustration only, the below-described subject matter will refer to a single central processing unit, although multiple processing units may be implemented. ACD systems are complex and are typically controlled by a real-time multitasking operating system. Real-time multitasking operating systems use various methods to allocate processing time among various tasks of the ACD. One known method of allocating time among the various processes is to perform a xe2x80x9ccontext switchxe2x80x9d at predetermined time intervals. For example, an interrupt occurring every ten to twenty milliseconds may be used to cause a context switch. That is, every ten or twenty milliseconds, the current task being executed is temporarily suspended and another task is begun. Usually, this occurs on a xe2x80x9ctime-slicexe2x80x9d basis so that all tasks are eventually serviced. There are numerous known schemes used to further xe2x80x9cfine-tunexe2x80x9d the context switching, such as priority order, rotating priority order, round-robin switching or a combination of priority and round-robin scheduling. Additionally, some tasks may be designated as xe2x80x9cnon-interruptiblexe2x80x9d or xe2x80x9cnon-switchablexe2x80x9d tasks during its entire execution time or a portion thereof, depending upon the critical nature of the task. Accordingly, real-time multitasking operating systems utilize an appropriate method for allocating computer processing time such that all software processes are permitted to perform their function.
However, known real-time multitasking operating systems may become overloaded or overburdened if required to perform too many tasks. In such a situation, response time will suffer which could lead to sluggish performance, system failures, or xe2x80x9ccrashes.xe2x80x9d In ACD systems, this may occur when the system is overloaded by routing more than a maximum number of telephone calls through the ACD system, adding too many agents, or requiring the system to perform additionally tasks, such as report generation, and diagnostics and the like that are beyond its capacity. To prevent overloading the ACD system, the processing time devoted to the processes must not be exceeded. By knowing the processing time devoted to each task, the engineers and technicians can monitor the available xe2x80x9cprocessor powerxe2x80x9d to determine whether the central processing unit can adequately handle the required processes. This is particularly useful when additional system tasks are proposed but not actually implemented. This typically occurs when a customer wishes to know how the ACD system will perform given added burdens. A need exists for a method capable of determining whether the capabilities of an ACD system are approaching or have exceeded the processing limits of the central processing unit as additional burdens are placed on the ACD system in real-time. A need also exists for a method capable of determining which process in a multitasking operating system uses a disproportional amount of processing time.
The available processing power is determined by the combination of the type of computer, microprocessor, or xe2x80x9cchipxe2x80x9d used, the speed of the microprocessor (frequency or clock speed), the efficiency of the software instructions (number of operands per instruction, number of bits in the instructions), input/output structure of the system, frequency of interrupts and the interrupt structure, and the like. Additional tasks may be added to the system and the scope or frequency of existing tasks can be increased if sufficient processor power exists.
However, known methods for determining whether sufficient processing power exists to handle additional capacity in an ACD system are inadequate. Typically, the tasks or increased load are added to the ACD system and technicians monitor the system to determine if any adverse results follow. If the efficiency of the system is reduced by more than an acceptable amount, the tasks are removed from the ACD system until performance is acceptable. This is essentially a xe2x80x9ctrial and errorxe2x80x9d approach.
Another known method utilizes a software command that is executed on an interrupt basis, for example, every ten milliseconds. This method provides an indication of the available processing xe2x80x9cpower.xe2x80x9d Every ten milliseconds an interrupt occurs and an accumulator function is executed which simply determines which process was running at the time that the ten millisecond interrupt occurred. A software accumulator associated with that particular process is then incremented (e.g., a xe2x80x9ctickxe2x80x9d is added to the value in the accumulator). Each individual process or task has its own software accumulator and each tick in the accumulator represents an addition of ten milliseconds of time. Since the interrupt occurs every ten milliseconds., it is assumed that the interrupted process had been executing for ten milliseconds. Accordingly, its accumulator is incremented.
However, this method suffers from significant disadvantages. First, accurate timing cannot be achieved because the xe2x80x9cgranularityxe2x80x9d or resolution of the timing function is too large. A relatively large value, for example, ten milliseconds, is used so as not to overburden the system with the accumulator process itself. If the accumulator process is executed too often (e.g., more than every ten milliseconds), it becomes part of the problem leading to sluggish system performance. Because of the large granularity, errors in time accumulate and become significant such that an accumulated time associated with a particular process is not an accurate reflection of the actual time devoted to the particular process. This known method is only adequate to identify a process that grossly and disproportionately uses processing time.
A second serious disadvantage of such a method is that the software accumulator for a particular process is only incremented if that process was running at the time that the ten millisecond interrupt occurred. For example, if process xe2x80x9cAxe2x80x9d was executing for five milliseconds, then process xe2x80x9cBxe2x80x9d was begun and the ten millisecond interrupt occurred, the software accumulator associated with process xe2x80x9cBxe2x80x9d is incremented while the software accumulator for process xe2x80x9cAxe2x80x9d is not modified because the accumulator function did not xe2x80x9cknowxe2x80x9d that process xe2x80x9cAxe2x80x9d had been executed. This problem is referred to as a xe2x80x9cboundary problemxe2x80x9d and leads to serious distortions in the amount of execution time reported for each process. Thus, the engineer or technician cannot rely upon the information provided and cannot determine the source of the problem, assuming that the problem is not an obvious problem where one process is the continuous source of grossly disproportionate time consumption.
A third significant disadvantage of the above-described software accumulator function is that it must be executed on a demand basis. That is, a supervisor or engineer must cause the function to be executed by typing a particular key sequence on a supervisory terminal. This causes the accumulator function to be executed on an instantaneous basis. The accumulator function executes for a predetermined amount of time and the results are inspected. Thus, the engineer can only inspect the results of the accumulator function at that particular time. There is no facility to permit the accumulator function to continuously execute to identify a problem that occurs at a distant point in time. Such a accumulator function executing continuously would soon cause the software counters to overflow, rendering the results meaningless.
Another method used to determine the time allocated to various software processes is to use a hardware emulator. A hardware emulator is a separate, relatively bulky device having a xe2x80x9cprocessor podxe2x80x9d attached to an xe2x80x9cumbilical cord.xe2x80x9d The processor pod contains a microprocessor that physically replaces the existing central processing unit of the ACD system and xe2x80x9ctakes overxe2x80x9d execution of the operating system. Typically, the microprocessor is identical to the central processing unit that it replaces. The emulator is used to set xe2x80x9cbreakpointsxe2x80x9d which cause to the system to halt when particular software addresses are fetched or when particular registers or memory locations are loaded with user-defined values. Once the system is halted, the engineer can inspect various registers and memory locations and may be able to determine the time interval between preselected breakpoints. This system functions well within a narrowly defined window in time and provides extremely accurate timing information, often with nanosecond resolution.
However, the emulator is bulky and cumbersome and is not easily used in the field or at customer sites. Additionally, extension cards or extender cards must be used to permit attachment of the processor pod. Use of extension cards causes unusual timing anomalies and bus errors induced by added capacitance and increased wire length of the extension cards. Further, the central processing unit of the ACD system cannot be operated at maximum speed due to the use of the processor pod. Generally, the emulator system is adequate to isolate timing problems occurring during a small interval in time, on the order of a few seconds, where precise timing within those few seconds is required. However, the emulator system is not adequate to isolate system-wide loading problems where usage over a relatively long period of time is at issue. It is also not practical to use the emulator system in the field or at a customer site.
Accordingly, it is an object of the present invention to provide a novel timing method and apparatus to substantially overcome above-described problems.
It is another object of the present invention to provide a novel timing method and apparatus that measures and profiles software processes of a real-time multitasking operating system of an ACD system.
It is a further object of the present invention to provide a novel timing method and apparatus that measures and reports the run-time characteristics of a real-time multitasking operating system of an ACD system.
It is also an object of the present invention to provide a novel timing method and apparatus that executes continuously on demand and periodically reports timing results of software process execution of a real-time multitasking operating system of an ACD system.
It is still an object of the present invention to provide a novel timing method and apparatus that accurately performs timing measurements of software processes in real-time with a selectable timing resolution.
It is yet another object of the present invention to provide a novel timing method and apparatus that utilizes a hardware timing device that is accessed within the context switching point of a real-time multitasking operating system of an ACD system.
Disadvantages of present software timers and software timing methods are substantially overcome with the present invention by providing a novel periodic process timer. In one embodiment, the periodic process timer is selectively activated through a supervisory display or may be programed to be activated at a predetermined future time. Once activated, the periodic processor timer runs continuously until disabled by a command. Periodically, the process timer reports its results to a file to prevent timer overflow. The files or output of the periodic process timer are arranged and organized to provide the engineer or technician with accurate data representative of the execution times for each selected software process.
The periodic process timer, in one embodiment, is embedded in the system software or operating system, and the granularity or the resolution of the timing measurement may be modified at compile time. Alternately, the timing resolution may be, for example, programmable in real time. The software forming the periodic process timer is embedded in the real-time operating system at a central point referred to as the xe2x80x9ccontext-switchingxe2x80x9d point. This is the single location in the operating system where processes are suspended and new processes are executed. Because only a single context-switching point exists, each software process is accurately timed, and no processes can execute without the periodic process timer software having access to its execution. Of course, the novel periodic process timer may still be implemented in an operating system having more than one context-switching point. In this situation, the periodic process timer software would be embedded at each point that context switching occurs.
The novel periodic process timer, in one embodiment, utilizes a hardware timing device in a manner similar to a stopwatch. When a software process is begun, the timer is cleared and started. When the process ends, the timer is inspected to determine the amount of elapsed time. The elapsed time is then added to a software counter or accumulator corresponding to the particular process or task. Each process to be monitored has a corresponding software counter. Periodically, at about an interval of one-hundred seconds, the results of the periodic process timer shown in the software counter or acevaulator are sent to or written to a file, for example, a disk file. The value of the software counters may be normalized or scaled so that the results are available to the engineer in a convenient format. Preferably, the number of bits provided by the hardware counter and the clock frequency supplied to the input of the hardware timer is sufficient to accommodate about two to six seconds of real-time recording. This represents the longest possible period of time that any one task may execute without interruption or a context-switch. However, most processes or tasks execute for a substantially shorter period of time.
The software counters or accumulators corresponding to each process preferably have a bit width sufficient to accommodate about one-hundred seconds of time. This means that about every one-hundred seconds, the value of the software counters are written to the disk file. This prevents counter or accumulator overflow. The files containing the accumulated values of the software counters may be separate or may represent a concatenated arrangement. In either situation, the periodic process timer may run indefinitely, limited only by the available disk space.
The novel periodic process timer is a significant development tool and sales aid. Often, customers desire to know, prior to purchase, certain performance characteristics of the ACD system. Additionally, customers and potential customers desire to know how a product will perform when certain environmental parameters are changed. Specifically, it is desirable to be able to predict performance characteristics when the number of incoming telephone calls is increased, when the number of agents is modified, when the duration of the incoming telephone calls is modified, and when customer-defined features are added. Such changes in the environmental parameters may significantly affect the performance of the ACD system. These environmental parameters may be changed during a simulation, as is known in the art. During such a simulation, the available or remaining processing capability may be monitored using the periodic process timer. The available processing capability of the ACD system provides an indication of how much additional burden the ACD system can effectively handle. Thus, the system response to new demands may be evaluated during operation of the ACD system.
The idle time of a microprocessor or central processor is usually designated as the lowest priority process or task since a processor is never truly idle, except in a xe2x80x9csleepxe2x80x9d state. Accordingly, if the idle process or task is executing for a large proportion of the total processing time, excess capability exists, and the ACD system can clearly handle additional demands. A customer may desire to know how close the ACD system is approaching its maximum capacity as features are added. For example, the processing capability may be at a level of about 50%. The customer may then request an evaluation of the processing capability when new features are added or system loading is increased. In this situation, for example, the number of telephone calls can be increased or features added either by simulating the change, or subjecting the ACD system to such actual changes. Accordingly, the novel periodic process timer may then show, for example, that the processing capability has changed from 50% usage to 70% usage, indicating that the changes to the environmental parameters resulted in a 20% increase in processor load. This is reflected by a corresponding 20% decrease allocated to the idle-time process. Such a demonstration may convince a prospective customer that the product can meet current and future demands.
Similarly, the novel periodic process timer may be used as a field diagnostic tool to determine if an increase in environmental parameters has placed too much of a burden on an existing ACD system. When the processing time devoted to the idle-time process approaches a low value, for example, ten percent, as indicated by the periodic process timer, the customer may need to perform system modifications, such as reducing the number incoming telephone calls. Alternately, the customer may elect to increase the capabilities of the ACD system or upgrade the system by adding various hardware components to increase system capability.
More specifically, the periodic process timer, in one embodiment, may be incorporated into a multi-tasking control program executed by a computer. The multi-tasking control program manages the allocation of processing time for a plurality of processes. The process timing method includes the steps of: a) initializing a plurality of accumulator values, each accumulator value corresponding to a process of the plurality of processes, each accumulator value defined to represent a total processing time for each process; b) recording a starting value of a counter device; c) activating the counter device prior to execution of a selected process has terminated; d) permitting the selected process to execute; e) stopping the counter device after execution of the selected process has terminated; f) reading and ending value of the counter device; g) determining a difference value between the starting value and the ending value; h) adding the difference value to the accumulator value corresponding to the selected process; i) continuously repeating steps (b) through (h) until a predetermined amount of time has elapsed, to obtain a total accumulator value representing the total processing time for each selected process; and j) saving the accumulator values for each selected process.